Simplify eslint configs, modernize eslint config for docsJS - #42270
Conversation
| }, | ||
| sourceType: 'script', | ||
| parserOptions: { | ||
| ecmaVersion: 2019 |
There was a problem hiding this comment.
You can't just use latest. What is latest now, won't be the same latest later and so on... IMHO we should just stop having hardcoded browser versions in .browserslistrc and just support latest. Then, this change would be OK too and we could drop babel and co altogether.
There was a problem hiding this comment.
To be fair our browserslist is outdated anyway or should I say incompatible with the CSS features we use in v6 (and maybe even v5 to some extent).
While Babel handles transpiling/polyfilling our JS, not sure about the CSS. I know we have autoprefixer in place but that handles only vendor prefixes not any sort of workarounds or polyfills. (Maybe postcss does?)
I wanted to open a discussion about this already, but due lack of time (as usual 😔) I wasn't able to, yet. I meant to propose to maybe use some baseline definition e.g. baseline widely available (see https://github.com/browserslist/browserslist?tab=readme-ov-file#queries). To read more about baseline in general you may want to check out https://web-platform-dx.github.io/web-features/. Besides that MDN or CanIUse shows the baseline support too, so I'd say it's already something that is well adopted.
Also I already locally tested some stylelint plugins to check if we use CSS that matches the browsers we wanted to support.
Those three I tried been stylelint-no-unsupported-browser-features, stylelint-browser-compat and stylelint-plugin-use-baseline.
There are pros and cons to all of them - stylelint-no-unsupported-browser-features and stylelint-browser-compat are more verbose about browser incompatibility like showing versions that don't support a certain feature, on the other hand stylelint-plugin-use-baseline doesn't. It just tell you that a feature isn't available.
On the positive side stylelint-plugin-use-baseline is very configurable compared to the other two and it looks like it's the most consistent in finding unsupported properties/values.
Eslint has support for baseline too: https://baselinejs.vercel.app/ or eslint-plugin-compat
Last but not least with our current browserslist we support 87.5% of global users (according to https://browsersl.ist/)
While baseline widely available with downstream covers 89.3%
Important
I have to mention that we use some CSS in v6 that isn't "widely available" yet because it's too new.
|
Superseded — everything here already landed on v6-dev via #42354 (commit d0ec50b):
Rebasing this branch onto current v6-dev leaves a zero-line diff ( On the review thread: the Closing as already-incorporated. |
3 participants
[].concat(...),Array.from(), and.split('')with the spread operator ([...iterable]) across source, tests, and site files. Where we're just iterating (not building an array), usefor...ofdirectly instead.arr[arr.length - 1]with.at(-1)in a handful of places.unicorn/prefer-spreadandunicorn/prefer-atas errors so we enforce these going forward.ecmaVersion: 2019and2020overrides for site files—our browser targets (Chrome 120+, Firefox 121+, Safari 15.6+) support well beyond that, so we just uselatesteverywhere now..eslintrc.jsonsince we use ESLint 10's flat config exclusively. It was unused and drifting out of sync.